Switch fallthrough to empty case statements inconsistent between GCC and Clang #636

nathanchance · 2019-08-12T18:48:54Z

While testing @Nathan-Huckleberry's patch (https://reviews.llvm.org/D64838):

../include/linux/signal.h:245:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
        case 1: ;
        ^
../include/linux/signal.h:245:2: note: insert '__attribute__((fallthrough));' to silence this warning
        case 1: ;
        ^
        __attribute__((fallthrough));
../include/linux/signal.h:245:2: note: insert 'break;' to avoid fall-through
        case 1: ;
        ^
        break;

This comes from include/linux/signal.h in siginitset and siginitsetinv:

static inline void siginitset(sigset_t *set, unsigned long mask)
{
	set->sig[0] = mask;
	switch (_NSIG_WORDS) {
	default:
		memset(&set->sig[1], 0, sizeof(long)*(_NSIG_WORDS-1));
		break;
	case 2: set->sig[1] = 0;
	case 1: ;
	}
}

static inline void siginitsetinv(sigset_t *set, unsigned long mask)
{
	set->sig[0] = ~mask;
	switch (_NSIG_WORDS) {
	default:
		memset(&set->sig[1], -1, sizeof(long)*(_NSIG_WORDS-1));
		break;
	case 2: set->sig[1] = -1;
	case 1: ;
	}
}

It appears that GCC and Clang disagree on emitting a diagnostic when falling through to an empty case statement.

C++ example because C doesn't work right now (#236): https://godbolt.org/z/dFJyAY

Not sure if that should be considering intentional or a bug but making a note of it because this warning appears 6849 times in an x86 allyesconfig build...

The text was updated successfully, but these errors were encountered:

nathanchance · 2019-08-12T18:52:56Z

I think this also falls under this issue:

../include/linux/jhash.h:113:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
        case 0: /* Nothing left to add */
        ^
../include/linux/jhash.h:113:2: note: insert 'break;' to avoid fall-through
        case 0: /* Nothing left to add */
        ^
        break;
../include/linux/jhash.h:152:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
        case 0: /* Nothing left to add */
        ^
../include/linux/jhash.h:152:2: note: insert 'break;' to avoid fall-through
        case 0: /* Nothing left to add */
        ^
        break;
12 warnings generated.

https://github.com/torvalds/linux/blob/v5.3-rc4/include/linux/jhash.h#L101

	case 2:  a += (u32)k[1]<<8;	/* fall through */
	case 1:  a += k[0];
		 __jhash_final(a, b, c);
	case 0: /* Nothing left to add */
		break;

nickdesaulniers · 2019-08-12T19:48:53Z

It appears that GCC and Clang disagree on emitting a diagnostic when falling through to an empty case statement.

Which does what? (Who warns, who does not)?

nathanchance · 2019-08-12T19:50:49Z

GCC does not warn, Clang does. Sorry, thought the godbolt link would have made that clear!

I am working through an x86 allyesconfig build after running Joe Perches's cvt_style perl script and most of the warnings I see from clang come from this pattern (falling through to the last case statement that either does nothing or breaks).

nathanchance · 2019-08-12T20:06:34Z

These are the few patterns that I am seeing, hopefully this is a little clearer: https://godbolt.org/z/xgkvIh

nathanchance · 2019-08-13T19:43:26Z

Joe filed a GCC bug, he thinks that GCC is wrong here:

https://lore.kernel.org/lkml/3078e553a777976655f72718d088791363544caa.camel@perches.com/

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432

Clang/GCC disagree on how to handle fall-through especially on handling the fall through comment in code. Temporarily disable it in the iwl7000 drivers. GCC 4.9.2 used in Chrome OS does not support this warning so any coverage loss should be minimal. Details: ClangBuiltLinux/linux#636 BUG=chromium:997991 TEST=kernel compiles with ToT clang. Signed-off-by: Manoj Gupta <manojgupta@google.com> Change-Id: I079e40f3c9282238dd1e4cb964976232fbe971a9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1792453 Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Commit-Queue: Manoj Gupta <manojgupta@chromium.org> Tested-by: Manoj Gupta <manojgupta@chromium.org>

Clang/GCC disagree on how to handle fall-through especially on handling the fall through comment in code. Temporarily disable it in the iwl7000 drivers. GCC 4.9.2 used in Chrome OS does not support this warning so any coverage loss should be minimal. Details: ClangBuiltLinux/linux#636 BUG=chromium:997991 TEST=kernel compiles with ToT clang. Signed-off-by: Manoj Gupta <manojgupta@google.com> Change-Id: I079e40f3c9282238dd1e4cb964976232fbe971a9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1792417 Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Commit-Queue: Manoj Gupta <manojgupta@chromium.org> Tested-by: Manoj Gupta <manojgupta@chromium.org>

Clang/GCC disagree on how to handle fall-through especially on handling the fall through comment in code. Temporarily disable it in the iwl7000 drivers. GCC 4.9.2 used in Chrome OS does not support this warning so any coverage loss should be minimal. Details: ClangBuiltLinux/linux#636 BUG=chromium:997991 TEST=kernel compiles with ToT clang. Signed-off-by: Manoj Gupta <manojgupta@google.com> Change-Id: I079e40f3c9282238dd1e4cb964976232fbe971a9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1792452 Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Manoj Gupta <manojgupta@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>

Clang/GCC disagree on how to handle fall-through especially on handling the fall through comment in code. Disable it in the iwl7000 drivers. Kernel 4.4 does not have the annotations for fall through so this warning was not testing anything on kernel 4.4 anyway. Details: ClangBuiltLinux/linux#636 BUG=chromium:997991 TEST=kernel compiles with ToT clang. Signed-off-by: Manoj Gupta <manojgupta@google.com> Change-Id: I079e40f3c9282238dd1e4cb964976232fbe971a9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1779318 Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Manoj Gupta <manojgupta@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>

This functionally reverts commit bfd7714 ("Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang"). clang enabled support for -Wimplicit-fallthrough in C in r369414 [1], which causes a lot of warnings when building the kernel for two reasons: 1. Clang does not support the /* fall through */ comments. There seems to be a general consensus in the LLVM community that this is not something they want to support. Joe Perches wrote a script to convert all of the comments to a "fallthrough" keyword that will be added to compiler_attributes.h [2] [3], which catches the vast majority of the comments. There doesn't appear to be any consensus in the kernel community when to do this conversion. 2. Clang and GCC disagree about falling through to final case statements with no content or cases that simply break: https://godbolt.org/z/c8csDu This difference contributes at least 50 warnings in an allyesconfig build for x86, not considering other architectures. This difference will need to be discussed to see which compiler is right [4] [5]. [1]: llvm/llvm-project@1e0affb [2]: https://lore.kernel.org/lkml/61ddbb86d5e68a15e24ccb06d9b399bbf5ce2da7.camel@perches.com/ [3]: https://lore.kernel.org/lkml/1d2830aadbe9d8151728a7df5b88528fc72a0095.1564549413.git.joe@perches.com/ [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [5]: ClangBuiltLinux/linux#636 Given these two problems need discussion and coordination, do not enable -Wimplicit-fallthrough with clang right now. Add a comment to explain what is going on as well. This commit should be reverted once these two issues are fully flushed out and resolved. Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Raphiel Rollerscaperers <rapherion@raphielgang.org>

[ Upstream commit e2079e9 ] This functionally reverts commit bfd7714 ("Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang"). clang enabled support for -Wimplicit-fallthrough in C in r369414 [1], which causes a lot of warnings when building the kernel for two reasons: 1. Clang does not support the /* fall through */ comments. There seems to be a general consensus in the LLVM community that this is not something they want to support. Joe Perches wrote a script to convert all of the comments to a "fallthrough" keyword that will be added to compiler_attributes.h [2] [3], which catches the vast majority of the comments. There doesn't appear to be any consensus in the kernel community when to do this conversion. 2. Clang and GCC disagree about falling through to final case statements with no content or cases that simply break: https://godbolt.org/z/c8csDu This difference contributes at least 50 warnings in an allyesconfig build for x86, not considering other architectures. This difference will need to be discussed to see which compiler is right [4] [5]. [1]: llvm/llvm-project@1e0affb [2]: https://lore.kernel.org/lkml/61ddbb86d5e68a15e24ccb06d9b399bbf5ce2da7.camel@perches.com/ [3]: https://lore.kernel.org/lkml/1d2830aadbe9d8151728a7df5b88528fc72a0095.1564549413.git.joe@perches.com/ [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [5]: ClangBuiltLinux/linux#636 Given these two problems need discussion and coordination, do not enable -Wimplicit-fallthrough with clang right now. Add a comment to explain what is going on as well. This commit should be reverted once these two issues are fully flushed out and resolved. Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

BugLink: https://bugs.launchpad.net/bugs/1848047 [ Upstream commit e2079e93f562c7f7a030eb7642017ee5eabaaa10 ] This functionally reverts commit bfd7714 ("Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang"). clang enabled support for -Wimplicit-fallthrough in C in r369414 [1], which causes a lot of warnings when building the kernel for two reasons: 1. Clang does not support the /* fall through */ comments. There seems to be a general consensus in the LLVM community that this is not something they want to support. Joe Perches wrote a script to convert all of the comments to a "fallthrough" keyword that will be added to compiler_attributes.h [2] [3], which catches the vast majority of the comments. There doesn't appear to be any consensus in the kernel community when to do this conversion. 2. Clang and GCC disagree about falling through to final case statements with no content or cases that simply break: https://godbolt.org/z/c8csDu This difference contributes at least 50 warnings in an allyesconfig build for x86, not considering other architectures. This difference will need to be discussed to see which compiler is right [4] [5]. [1]: llvm/llvm-project@1e0affb [2]: https://lore.kernel.org/lkml/61ddbb86d5e68a15e24ccb06d9b399bbf5ce2da7.camel@perches.com/ [3]: https://lore.kernel.org/lkml/1d2830aadbe9d8151728a7df5b88528fc72a0095.1564549413.git.joe@perches.com/ [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [5]: ClangBuiltLinux/linux#636 Given these two problems need discussion and coordination, do not enable -Wimplicit-fallthrough with clang right now. Add a comment to explain what is going on as well. This commit should be reverted once these two issues are fully flushed out and resolved. Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

groeck · 2019-11-06T22:16:43Z

I am kind of lost about:

	case 2:  a += (u32)k[1]<<8;	/* fall through */
	case 1:  a += k[0];
		 __jhash_final(a, b, c);
	case 0: /* Nothing left to add */
		break;

Isn't there a "fall through" missing before "case 0:" ? What am I missing ?

groeck · 2019-11-06T22:22:10Z

Never mind, I can see the discussion with the gcc community. Sorry for the noise.

This functionally reverts commit bfd7714 ("Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang"). clang enabled support for -Wimplicit-fallthrough in C in r369414 [1], which causes a lot of warnings when building the kernel for two reasons: 1. Clang does not support the /* fall through */ comments. There seems to be a general consensus in the LLVM community that this is not something they want to support. Joe Perches wrote a script to convert all of the comments to a "fallthrough" keyword that will be added to compiler_attributes.h [2] [3], which catches the vast majority of the comments. There doesn't appear to be any consensus in the kernel community when to do this conversion. 2. Clang and GCC disagree about falling through to final case statements with no content or cases that simply break: https://godbolt.org/z/c8csDu This difference contributes at least 50 warnings in an allyesconfig build for x86, not considering other architectures. This difference will need to be discussed to see which compiler is right [4] [5]. [1]: llvm/llvm-project@1e0affb [2]: https://lore.kernel.org/lkml/61ddbb86d5e68a15e24ccb06d9b399bbf5ce2da7.camel@perches.com/ [3]: https://lore.kernel.org/lkml/1d2830aadbe9d8151728a7df5b88528fc72a0095.1564549413.git.joe@perches.com/ [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [5]: ClangBuiltLinux/linux#636 Given these two problems need discussion and coordination, do not enable -Wimplicit-fallthrough with clang right now. Add a comment to explain what is going on as well. This commit should be reverted once these two issues are fully flushed out and resolved. Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

In preparation to enable -Wimplicit-fallthrough for Clang, mark switch cases where it is expected to fall through. This patch adds four fallthrough annotations that, together, fix almost 80,000 warnings when building Linux 5.9-rc3 with Clang 12.0.0 and this[1] change reverted. Notice that in order to enable -Wimplicit-fallthrough for Clang, such change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing a fallthrough annotation or a break/continue/return statement when falling through to any kind of case statement. Otherwise, making an exception turns into a bogus sort of a special case scenario. Something important to keep in mind is that the point of enabling options like -Wimplicit-fallthrough is to prevent the human error and aid the developers in spotting bugs before their code is even submitted/committed, therefore elimitating classes of bugs. So, in order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely. [1] commit e2079e9 ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d55 ("Makefile: Globally enable fall-through warning") Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add break statements instead of letting the code fall through to the next case. This patch adds four break statements that, together, fix almost 80,000 warnings when building Linux 5.9-rc3 with Clang 12.0.0 and this[1] change reverted. Notice that in order to enable -Wimplicit-fallthrough for Clang, such change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, min order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. [1] commit e2079e9 ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d55 ("Makefile: Globally enable fall-through warning") Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add break statements instead of letting the code fall through to the next case. This patch adds four break statements that, together, fix almost 80,000 warnings when building Linux 5.9-rc3 with Clang 12.0.0 and this[1] change reverted. Notice that in order to enable -Wimplicit-fallthrough for Clang, such change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, min order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. [1] commit e2079e9 ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux/linux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d55 ("Makefile: Globally enable fall-through warning") Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add break statements instead of letting the code fall through to the next case. This patch adds four break statements that, together, fix almost 40,000 warnings when building Linux 5.10-rc1 with Clang 12.0.0 and this[1] change reverted. Notice that in order to enable -Wimplicit-fallthrough for Clang, such change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, in order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. [1] commit e2079e9 ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d55 ("Makefile: Globally enable fall-through warning") Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

nickdesaulniers · 2020-11-20T23:56:29Z

https://reviews.llvm.org/D91895

nathanchance · 2020-11-22T01:13:59Z

https://lore.kernel.org/lkml/20201121124019.21116-1-ogabbay@kernel.org/

Clang's version of the warning would have caught this ¯\_(ツ)_/¯

drivers/misc/habanalabs/gaudi/gaudi.c:5439:2: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
        default:
        ^
drivers/misc/habanalabs/gaudi/gaudi.c:5439:2: note: insert '__attribute__((fallthrough));' to silence this warning
        default:
        ^
        __attribute__((fallthrough));
drivers/misc/habanalabs/gaudi/gaudi.c:5439:2: note: insert 'break;' to avoid fall-through
        default:
        ^
        break;
1 warning generated.

nickdesaulniers · 2020-11-24T01:28:20Z

kernel/sched/core.o (for aarch64) and a few others I haven't yet tracked down produces a -Wimplicit-fallthrough with no line info...

nickdesaulniers · 2020-12-03T19:50:39Z

Based on @kees ' feedback, I'm going to close this as wontfix. I'm happy to reopen/revisit, but I think we'll ultimately land the series @GustavoARSilva is working on in #236 .

tansy · 2021-05-10T16:25:37Z

Have you tried to use comment (/* fall through */ or /* fallthrough */, whatever works) as it's been done here, or here?

nathanchance · 2021-05-10T17:21:27Z

Clang does not and will not support fall through comments:

https://godbolt.org/z/fW4zx1dnG

https://llvm.org/pr43465

https://reviews.llvm.org/D73852

The conversion to __attribute__((__fallthrough__)) is being tracked at #236.

This issue is concerned with the fact that Clang and GCC disagree on warning on cases that fallthrough to break, return, etc:

https://godbolt.org/z/vvorYjfPj

tansy · 2021-05-18T13:16:37Z

Ok, I get that.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add break statements instead of letting the code fall through to the next case. This patch adds four break statements that, together, fix almost 40,000 warnings when building Linux 5.10-rc1 with Clang 12.0.0 and this[1] change reverted. Notice that in order to enable -Wimplicit-fallthrough for Clang, such change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, in order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. [1] commit e2079e9 ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux/linux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d55 ("Makefile: Globally enable fall-through warning") Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Divyanshu-Modi <divyan.m05@gmail.com>

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly add break statements instead of letting the code fall through to the next case. This patch adds four break statements that, together, fix almost 40,000 warnings when building Linux 5.10-rc1 with Clang 12.0.0 and this[1] change reverted. Notice that in order to enable -Wimplicit-fallthrough for Clang, such change[1] is meant to be reverted at some point. So, this patch helps to move in that direction. Something important to mention is that there is currently a discrepancy between GCC and Clang when dealing with switch fall-through to empty case statements or to cases that only contain a break/continue/return statement[2][3][4]. Now that the -Wimplicit-fallthrough option has been globally enabled[5], any compiler should really warn on missing either a fallthrough annotation or any of the other case-terminating statements (break/continue/return/ goto) when falling through to the next case statement. Making exceptions to this introduces variation in case handling which may continue to lead to bugs, misunderstandings, and a general lack of robustness. The point of enabling options like -Wimplicit-fallthrough is to prevent human error and aid developers in spotting bugs before their code is even built/ submitted/committed, therefore eliminating classes of bugs. So, in order to really accomplish this, we should, and can, move in the direction of addressing any error-prone scenarios and get rid of the unintentional fallthrough bug-class in the kernel, entirely, even if there is some minor redundancy. Better to have explicit case-ending statements than continue to have exceptions where one must guess as to the right result. The compiler will eliminate any actual redundancy. [1] commit e2079e9 ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now") [2] ClangBuiltLinux/linux#636 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 [4] https://godbolt.org/z/xgkvIh [5] commit a035d55 ("Makefile: Globally enable fall-through warning") Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Divyanshu-Modi <divyan.m05@gmail.com> Signed-off-by: Dakkshesh <dakkshesh5@gmail.com>

nathanchance added question Question asked by issue author. polish Not a correctness bug, but will improve code performance or size labels Aug 12, 2019

nathanchance mentioned this issue Aug 27, 2019

travis: Bump LLVM version ClangBuiltLinux/continuous-integration#204

Merged

nathanchance mentioned this issue Feb 8, 2020

Enable -Wimplicit-fallthrough for C #236

Closed

nickdesaulniers assigned nhukc Jun 3, 2020

nickdesaulniers unassigned nhukc Sep 1, 2020

GustavoARSilva mentioned this issue Nov 17, 2020

Enable -Wimplicit-fallthrough for Clang KSPP/linux#115

Closed

nickdesaulniers added the [PATCH] Submitted A patch has been submitted for review label Nov 20, 2020

nickdesaulniers self-assigned this Nov 20, 2020

nickdesaulniers closed this as completed Dec 3, 2020

nickdesaulniers added wontfix This will not be worked on known difference known difference between GNU and LLVM; maybe unresolvable labels Dec 3, 2020

nathanchance mentioned this issue Mar 28, 2022

Implicit fall-through error in arch/x86/kvm/cpuid.c #1616

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Switch fallthrough to empty case statements inconsistent between GCC and Clang #636

Switch fallthrough to empty case statements inconsistent between GCC and Clang #636

nathanchance commented Aug 12, 2019

nathanchance commented Aug 12, 2019

nickdesaulniers commented Aug 12, 2019 •

edited

nathanchance commented Aug 12, 2019

nathanchance commented Aug 12, 2019

nathanchance commented Aug 13, 2019

groeck commented Nov 6, 2019

groeck commented Nov 6, 2019

nickdesaulniers commented Nov 20, 2020

nathanchance commented Nov 22, 2020

nickdesaulniers commented Nov 24, 2020 •

edited

nickdesaulniers commented Dec 3, 2020

tansy commented May 10, 2021 •

edited

nathanchance commented May 10, 2021

tansy commented May 18, 2021

Switch fallthrough to empty case statements inconsistent between GCC and Clang #636

Switch fallthrough to empty case statements inconsistent between GCC and Clang #636

Comments

nathanchance commented Aug 12, 2019

nathanchance commented Aug 12, 2019

nickdesaulniers commented Aug 12, 2019 • edited

nathanchance commented Aug 12, 2019

nathanchance commented Aug 12, 2019

nathanchance commented Aug 13, 2019

groeck commented Nov 6, 2019

groeck commented Nov 6, 2019

nickdesaulniers commented Nov 20, 2020

nathanchance commented Nov 22, 2020

nickdesaulniers commented Nov 24, 2020 • edited

nickdesaulniers commented Dec 3, 2020

tansy commented May 10, 2021 • edited

nathanchance commented May 10, 2021

tansy commented May 18, 2021

nickdesaulniers commented Aug 12, 2019 •

edited

nickdesaulniers commented Nov 24, 2020 •

edited

tansy commented May 10, 2021 •

edited